Thanks for working on this! Though I would still be interested in allowing the user to disable the Expect behavior entirely as well within the same option somehow. There's effectively two states for this feature:

1. Expect is enabled, and has a specific timeout.
2. Expect is disabled, and a timeout isn't applicable.

Generally I've been moving towards grouping options like this into independent structs because it makes it more clear when an option is applicable. For example, if enabling/disabling Expect were to be a separate option, it would be possible to do something like

Request::post("...")
    .expect_100_enabled(false)
    .expect_100_timeout(Duration::from_millis(100))

Which while a naive example, demonstrates how the user might get confused (and trust me, experience tells me that users will get confused about things that were obvious to me as an author of the code). If we can use types to completely prevent the user from setting a timeout if Expect is disabled, then the behavior is more self-documenting. If we add expect_100_timeout as-is now, we can't really change our mind about this.

Honestly, to be transparent I hate holding up PRs when it is sometimes hard enough to get people to contribute to open source as it is. But I also am inspired by the Rust project itself to hold a very high view of API design and want to make sure we think through all the angles before adding new APIs.

Anyway, here's some thoughts in my head right now:

• expect_100 feels weird to say (probably because it isn't a noun but rather an imperative statement); is there a better word for describing this feature? If not we might just be stuck with it.
• This feature is very enum-like (enum Expect100 { Disabled, Enabled(Duration) }) but I usually avoid enums in public APIs in favor of opaque structs if it is possible that more configuration points might be added to it in the future. (Since adding a field to an enum variant is a breaking change, but adding one to an opaque struct with a default value doesn't have to be breaking.)

Closed in favor of #340.